Dynamically loading program code over a push-based network

ABSTRACT

Programming code, such as dynamically loadable program code used in object oriented programming languages, may be pushed over a unidirectional communication link, such as though a transmitter tower transmission or one-way networking communication protocol. A manifest is created that includes identifiers of programming code that will be pushed onto the unidirectional communication link, where the manifest includes a push schedule. A receiver of the manifest retrieves pushed code of interest according to the schedule. Purchasing data may also be included in the manifest. Programming code may include decryption techniques to allow for pay-per-use retrieval of premium content.

FIELD OF THE INVENTION

[0001] The invention generally relates to pushing programming code overunidirectional communication links, and more particularly, to pushingdynamically loadable program code, such as an object-oriented classdefinition, over the unidirectional communication link.

BACKGROUND

[0002]FIG. 1 illustrates a general prior art hardware environment forpushing data to a receiving computing device.

[0003] As illustrated, there is a data-pushing device 100, such as oneor more network servers or other computing devices, that pushes dataonto a network 102. The data-pushing device is responsible forgenerating or forwarding data that is ultimately received by a receivingcomputing device 104. The network can be any combination of conventionaland proprietary networks such as an intranet or the Internet.

[0004] A receiving computing device 104, also in communication with thenetwork, receives the pushed data. Various protocols for receivingpushed data are known in the art. For example, see the PointCast systemby EntryPoint of San Diego, Calif. Generally, the receiving computingdevice 104 listens to a particular data channel, e.g., a TransmissionControl Protocol/Internet Protocol (TCP/IP) network port, broadcastchannel, frequency range, etc. for data pushed by the data-pushingdevice 100.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The features and advantages of the present invention will becomeapparent from the following detailed description of the presentinvention in which:

[0006]FIG. 1 illustrates a general prior-art hardware environment forpushing data to a receiving computing device.

[0007]FIG. 2 illustrates a variation on the FIG. 1 push environment, inwhich the network includes wireless networks.

[0008]FIG. 3 is a flowchart, according to one embodiment of theinvention, for pushing programming code over a unidirectionalcommunication link.

[0009]FIG. 4 illustrates a receiver receiving pushed data in accordancewith the FIG. 3 embodiment.

[0010]FIG. 5 illustrates use of pushed dynamically loadable data tofacilitate a pay-per-use environment.

[0011]FIG. 6 illustrates a suitable computing environment in whichcertain aspects of the invention may be implemented.

DETAILED DESCRIPTION

[0012] Modern programming languages provide for dynamically loadable, ormodular, program code For example, an object-oriented programming (OOP)environment is one in which a program designer defines not only the datatype of a data structure, but also the types of operations (e.g.,functions/procedures) that can be applied to the data structure. Thedata structure for a class becomes an object including both data andfunctions/procedures. A “class” is a category of such objects, and inmodern OOP environments, to avoid unnecessary resource consumption, aclass can be dynamically loaded and unloaded to conserve resources.

[0013] As will be discussed below, dynamic loading can be effected overa push-type of networking environment. For example, identification dataof a class can be announced according to the Service AdvertisingProtocol (SAP)/Session Description Protocol (SDP) protocol, and theclass definition broadcast accordingly. Alternatively, a manifest can bedefined that contains identifying data for the definition of a class,and a schedule indicating when a second push will be made that containsthe actual program code for the identified class. A programmingenvironment and/or application program can then use a custom classloader to integrate, when needed, pushed classes.

[0014] In this description and claims that follow, the term manifest isintended to include both transmission of a manifest, or a SAP/SDP typeof announcement of its contents.

[0015]FIG. 2 illustrates a variation on the FIG. 1 push environment, inwhich the network 102 includes wireless networks. Wireless networksinclude short-range wireless networks including wireless LANbridges/routers, Bluetooth (a standard promoted by 3Com, Ericsson,Intel, IBM, Lucent, Microsoft, Motorola, Nokia, and Toshiba), or thelike, and long-range wireless networks such as microwave systems,satellite systems, cellular communication systems, televisiontransmission towers, etc.

[0016] In one embodiment, wireless transmitters comprise a completetransport data pathway between a transmission tower 204 and a receiver,such as a set top box 208, personal digital assistant, portablecomputer, handheld computer, wireless appliance, or other receivingdevice. In another embodiment, the wireless signal is partially carriedon a physical medium, such as a wire, fiber optic, or other medium,before being received by the set top box 208. Network 206 may or may notbe entirely wireless.

[0017] Assuming the wireless transmission is an audio and/or visualsignal, such as a television signal, a transmitting device 200, whichmay be a computer or other device providing television signals,transmits multiple television data streams to a multiplexer 202. Forexample, in digital television, Moving Picture Experts Group (MPEG)-2data transport streams would be emitted from the multiplexer. Atransport stream comprises multiple elementary streams of audio, video,and/or other “data” that is multiplexed and marked with a packetidentifier (PID). Under the United States Advanced Television SystemsCommittee (ATSC) digital television standard, a single “channel” isallotted 19.2 Mbps bandwidth. A single television program typicallycomprises elementary data streams for video and each supported audiolanguage. With data compression, the program may not consume allavailable bandwidth for the channel, so the program may become one ofseveral “virtual channels” embedded within the physical spectrumallotted to a broadcaster.

[0018] The multiplexer combines these multiple data streams into asingle transmission that is transmitted by a tower 204. Thistransmission is sent over a network 206, and received by a set top box208, such as a cable television decoding-box, computer device with atelevision decoder, or other television-aware device.

[0019]FIG. 3 is a flowchart, according to one embodiment of theinvention, for pushing programming code, such as dynamically loadableprogram code, over a unidirectional communication link such asillustrated in FIG. 1 or FIG. 2.

[0020] The unidirectional communication link may be physicallyunidirectional, as in a transmission from a broadcast tower, orlogically unidirectional, as in a unidirectional communication protocol.It is assumed herein that programming code for Java classes is pushed toa receiver. However, the disclosed principles and techniques are equallyapplicable to Objective-C, C++, SmallTalk, Modula-3, Component ObjectModel (COM), and other object oriented programming languages andenvironments, and the invention is not limited in this respect. It willbe appreciated by one skilled in the art that other data structures,besides classes, may be pushed as well. For example, a Dynamic LinkLibrary (DLL), or equivalent, having known entry points and structuremay be used.

[0021] In an object oriented programming environment such as Java, aclass encapsulates data, methods and procedures that operate on datainput to an instance of the class, and produce appropriate output.Classes are usually collected into libraries for solving particularproblems. Java libraries are called “Java archives,” or JAR files. Tominimize memory requirements and facilitate a more dynamic programmingmodel, Java execution environments defer loading a class into systemmemory until the class is utilized by an executing application program.

[0022] When a class is referenced, if it is not already loaded, it isdynamically loaded and made available to an executing program. Loadingrequires that a standard location (or locations) be searched for thereferences class, e.g., to locate a JAR file or other storage of classdefinition. In Java, an environment variable (or equivalent) called“CLASSPATH” is expected to exist and indicate a search path for locatingclass definitions. For example, CLASSPATH may point todirectories/folders containing class definitions and/or JAR files, ordirectly reference a data file storing archives therein. If a classcannot be found and loaded after searching the CLASSPATH environment,loading fails and the corresponding call within the application programfails.

[0023] Thus, in one embodiment, to load dynamically loadable programcode over a push-type networking environment, a manifest is firstprepared 300 corresponding to the dynamically loadable code. Themanifest comprises an identifier 302 that identifies the classdefinition so that the class can be properly loaded during execution ofan application program. In Java, the class definition identifiercomprises a package name followed by a relative class name. For example,the “String” class is part of the “java.lang” package, and is thereforeproperly identified as “java.lang.String”. Other programmingenvironments may utilize other identifying data, such as the name of theclass, and/or a globally unique identifier (GUID) for the class, and/ora class context, and/or class dependencies.

[0024] In one embodiment, the manifest further comprises a push schedule304, or availability schedule, indicating when class definitionsreferenced within the manifest will be pushed onto a unidirectionalcommunication link. In this embodiment, the manifest may furthercomprise a retrieval source 306 if class definitions may be received onone of several unidirectional communication pathways. Other related data308 may also be stored in the manifest to facilitate routing,verification, billing, or manifest related transactions.

[0025] In another embodiment, rather than utilizing a manifest, insteadits contents may be directly transmitted over the unidirectionalcommunication link. In this embodiment, an announcement may be broadcastusing the SAP/SDP, or equivalent, which indicates an identifier anddescription of a session, e.g., data to identify dynamically loadableprogramming code to be pushed, a location from which the code can beretrieved, e.g., a multicast addresses/port for the session, and aschedule of when the code will be pushed.

[0026] After creating the manifest, it is pushed 310 onto aunidirectional communication link. Then, in accordance with the pushschedule, the dynamically loadable code (e.g., class) referenced by themanifest is pushed 312 onto the unidirectional communication link.

[0027]FIG. 4 illustrates a receiver receiving pushed data in accordancewith the FIG. 3 embodiment. As illustrated, the receiver listens 400for, and receives 402, a pushed manifest. The manifest is parsed 404 todetermine 406 identifiers for dynamically loadable code referencedwithin the manifest. These identifiers are stored 408 within a localmemory, such as volatile or non-volatile storage. As discussed above,the manifest contents may be directly transmitted with SAP/SDP typeannouncements, in which case the receiver listens for announcements todetermine identifiers for dynamically loadable code.

[0028] A Java application program may be executed 410. When itreferences 412 a class for the first time, a search 414 may be performedto locate the class, e.g., the CLASSPATH environment is searched.Assuming searching the CLASSPATH fails, a search 416 may be performed tolocate the class among pushed class identifiers stored 408 within thelocal memory. If an appropriate class identifier(s) is located, theschedule corresponding to the identifier may be inspected 418.Dynamically loadable programming code, e.g., a Java class file, may thenbe retrieved 420 from a unidirectional communication link according tothe schedule. If SAP/SDP type broadcasting is in use, the dynamicallyloadable programming code may be retrieved from the multicastaddress/port indicated in the session's announcement.

[0029] In one embodiment, the retrieved dynamically loadable code may beadded to the existing CLASSPATH environment so as to avoid futurelatency in utilizing the retrieved code. In one embodiment, theCLASSPATH comprises a combination of volatile and nonvolatile storage.In this embodiment, standard classes may be stored in nonvolatilestorage, such as (erasable) programmable read-only memory (PROM),non-volatile random access memory (NVRAM), complementary metal oxidesemiconductor (CMOS), hard-drives, memory sticks, etc. Retrieved code,however, may be stored in volatile storage, e.g., random access memory(RAM).

[0030] Thus, for example, portable electronics, set-top boxes, or otherelectronics not configured with mass storage may be shipped withstandard class definitions, and temporarily acquire auxiliary classes asneeded during execution of an application program.

[0031] After retrieval 420, the dynamically loadable code is loaded 422in a manner customary to the program language environment in use forexecution 424 by the application program. Note that loading 422 may beperformed asynchronously to execution of the application program causingthe retrieval.

[0032] In addition, retrieval and loading may be performed transparentlyby an operating system, programming environment, or the applicationprogram depending on receiver environment configuration. For example, aJava runtime environment may determine a class needs to be retrieved 420from a unidirectional communication link, and then load the class 422without an application program becoming aware of the retrieval process.

[0033]FIG. 5 illustrates use of pushed dynamically loadable data tofacilitate a pay-per-use environment. Typical pay-per-use environmentsinclude television, telephone, or computer network broadcast systems,where one or more “premium” data channels are encrypted and transmittedto a receiver, and the receiver can not use the encrypted data withoutobtaining a decrypting ability.

[0034] In this illustrated embodiment, pushed manifests discussed aboveinclude identifiers for decryption classes that allow a receiving deviceto permanently or temporarily obtain encryption ability. The period ofavailability for decryption capability may be specified in the manifest,or regulated by local and/or remote policies. In one embodiment,temporary encryption is achieved by storing decryption classes involatile memory that is cleared when a receiving device is reset, powercycled, etc. Clearance may also be according to a clearance schedule,such as hourly, daily, weekly, etc., or according to a scheduleindicated within a manifest, e.g., automatic clearance after a certainnumber of uses, or after an elapsed time after first use, etc.

[0035] Thus, a computing device, such as a set top box or portableelectronic receiver, e.g., portable television, personal digitalassistant, cellular telephone, portable computer, wireless appliance, orthe like, executes 500 a control program, such as an operating system orapplication program. The control program receives 502 a manifest thatincludes an identifier and push schedule for a decryption class, as wellas purchasing data indicating a cost associated with obtaining thepremium data by way of the decryption class. A user of the device elects504, e.g., indicates by way of a graphical user interface, selection ofa button on the computing device, etc., a desire to purchase the premiumdata in accordance with the purchasing data. In response, an appropriatepurchase transaction occurs 506 according to the purchasing data in themanifest.

[0036] Note that purchase transactions are intended to includepurchasing protocols making use of third-party processing and/or billingarrangements. Since the communication link is unidirectional, it isassumed an alternative communication arrangement exists to effectpayment. For example, the computing device may have an internal modem incommunication with a telephone service, a network interface incommunication with a network, or other communication pathway. purchasesmay be made immediately, or performed on a delayed basis, e.g., thecomputing device receives election 504 of a purchase, and decryption isperformed on assumption that payment will eventually be secured. Delayedpayment facilitates using portable receivers intermittently connected toan alternative communication arrangement.

[0037] After the purchase transaction 506, the computing deviceretrieves 508 an appropriate decryption class from the unidirectionalcommunication link in accordance with the push schedule. The decryptionclass may be installed 510 as indicated by the manifest, e.g., it may beinstalled either permanently or temporarily. In a Java-type executionenvironment, the decryption class is installed within the CLASSPATHenvironment. The decryption class is then executed 512 by the controlprogram to decrypt desired data.

[0038] In one embodiment, to prevent theft of the decryption class, thedecryption class is itself encoded within a private key of apublic/private key pairing in a public key cryptosystem. Thecommunication device may be configured to contain the public key of thepairing, and the communication device decrypts the decryption class withthe public key only after purchase transaction 506. In such fashion,decryption classes can be blindly pushed onto an unsecuredunidirectional communication link without regard to illicit theft ofservices.

[0039]FIG. 6 and the following discussion are intended to provide abrief, general description of a suitable computing environment in whichcertain aspects of the illustrated invention may be implemented.

[0040] An exemplary system for implementing the invention includes acomputing device 600 having system bus 602 for coupling variouscomputing device components. Typically, attached to the bus arenon-programmable and programmable processors 604, a memory 606 (e.g.,RAM, ROM), storage devices 608, a video interface 610, and input/outputinterface ports 612. Storage devices include hard-drives, floppy-disks,optical storage, magnetic cassettes, tapes, flash memory cards, memorysticks, digital 20 video disks, and the like.

[0041] The invention may be described by reference to differenthigh-level program modules and/or low-level hardware contexts. Thoseskilled in the art will realize that program modules can be interchangedwith low-level hardware instructions. program modules includeprocedures, functions, programs, components, data structures, and thelike, for performing particular tasks or implementing particularabstract data types. Modules may be incorporated into single andmulti-processor computing devices, Personal Digital Assistants (PDAs),cellular telephones, portable computers, handheld computers, wirelessappliances, and the like. Thus, the storage systems and associated mediacan store data and executable instructions for the computing device.

[0042] The computing device is expected to operate in a networkedenvironment using logical connections to one or more remote computingdevices 614, 616 through a network interface 618, modem 620, or othercommunication pathway. Computing devices may be interconnected by way ofa network 622 such as an intranet, the Internet, or other network.Modules may be implemented within a single computing device, orprocessed in a distributed network environment, and stored in both localand remote memory. Thus, for example, with respect to the illustratedembodiments, assuming computing device 600 is a transmitter of pusheddynamically loadable programming code, then remote devices 614, 616 mayrespectively be a set top box and a portable wireless receiver of thepushed code.

[0043] It will be appreciated that remote computing devices 614, 616 maybe configured like computing device 600, and therefore include many orall of the elements discussed for computing device. It should also beappreciated that computing devices 600, 614, 616 may be embodied withina single device, or separate communicatively-coupled components, and mayinclude or be embodied within routers, bridges, peer devices, webservers, and application programs utilizing network applicationprotocols such as the HyperText Transfer Protocol (HTTP), File Transferprotocol (FTP), and the like.

[0044] Having described and illustrated the principles of the inventionwith reference to illustrated embodiments, it will be recognized thatthe illustrated embodiments can be modified in arrangement and detailwithout departing from such principles.

[0045] And, even though the foregoing discussion has focused onparticular embodiments, it is understood that other configurations arecontemplated. In particular, even though expressions such as “in oneembodiment,” “in another embodiment,” or the like are used herein, thesephrases are meant to generally reference embodiment possibilities, andare not intended to limit the invention to particular embodimentconfigurations. As used herein, these terms may reference the same ordifferent embodiments, and unless implicitly or expressly indicatedotherwise, embodiments are combinable into other embodiments.Consequently, in view of the wide variety of permutations to theabove-described embodiments, the detailed description is intended to beillustrative only, and should not be taken as limiting the scope of theinvention.

[0046] What is claimed as the invention, therefore, is all suchmodifications as may come within the scope and spirit of the followingclaims and equivalents thereto.

APPENDIX A

[0047] William E. Alford, Reg. No. 37,764; Farzad E, Amini, Reg. No.42,261; William Thomas Babbitt, Reg. No. 39,591; Carol F. Barry, Reg.No. 41,600; Jordan Michael Becker, Reg. No. 39,602; Lisa N. Benado, Reg.No. 39,995; Bradley J. Bereznak, Reg. No. 33,474; Michael A. Bernadicou,Reg. No. 35,934; Roger W. Blakely, Jr., Reg. No. 25,831; R. AlanBurnett, Reg. No. 46,149; Gregory D. Caldwell, Reg. No. 39,926; AndrewC. Chen, Reg. No. 43,544; Thomas M. Coester, Reg. No. 39,637; Donna JoConingsby, Reg. No. 41,684; Florin Corie, Reg. No. 46,244; Dennis M.deGuzman, Reg. No. 41,702; Stephen M. De Klerk, Reg. No. P46,503;Michael Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No.37,813; Justin M. Dillon, Reg. No. 42,486; Sanjeet Dutta, Reg. No.P46,145; Matthew C. Fagan, Reg. No. 37,542; Tarek N. Fahmi, Reg. No.41,402; George Fountain, Reg. No. 37,374; James Y. Go, Reg. No. 40,621;James A. Henry, Reg. No. 41,064; Willmore F. Holbrow III, Reg. No.P41,845; Sheryl Sue Holloway, Reg. No. 37,850; George W Hoover II, Reg.No. 32,992; Eric S. Hyman, Reg. No. 30,139; William W. Kidd, Reg. No.31,772; Sang Hui Kim, Reg. No. 40,450; Walter T. Kim, Reg. No. 42,731;Eric T. King, Reg. No. 44,188; Erica W. Kuo, Reg. No. 42,775; George B.Leavell, Reg. No. 45,436; Kurt P. Leyendecker, Reg. No. 42,799; GordonR. Lindeen III, Reg. No. 33,192; Jan Carol Little, Reg. No. 41,181;Robert G. Litts, Reg. No. 46,876; Joseph Lutz, Reg. No. 43,765; MichaelJ. Mallie, Reg. No. 36,591; Andre L. Marais, under 37 C.F.R. § 10.9(b);Paul A. Mendonsa, Reg. No. 42,879; Clive D. Menezes, Reg. No. 45,493;Chun M. Ng, Reg. No. 36,878; Thien T. Ngugen, Reg. No. 43,835; Thinh V.Nguyen, Reg. No. 42,034; Dennis A. Nicholls, Reg. No. 42,036; Daniel E.Ovanezian, Reg. No. 41,236; Kenneth B. Paley, Reg. No. 38,989; Gregg A.Peacock, Reg. No. 45,001; Marina Portnova, Reg. No. P45,750; William F.Ryann, Reg. 44,313; James H. Salter, Reg. No. 35,668; William W. Schaal,Reg. No. 39,018; James C. Scheller, Reg. No. 31,195; Jeffrey S.Schubert, Reg. No. 43,098; George Simion, Reg. No. P47,089; Jeffrey SamSmith, Reg. No. 39,377; Maria McCormack Sobrino, Reg. No. 31,639;Stanley W. Sokoloff, Reg. No. 25,128; Judith A. Szepesi, Reg. No.39,393; Vincent P. Tassinari, Reg. No. 42,179; Edwin H. Taylor, Reg. No.25,129; John F. Travis, Reg. No. 43,203; Joseph A. Twarowski, Reg. No.42,191; Mark C. Van Ness, Reg. No. 39,865; Thomas A. Van Zandt, Reg. No.43,219; Lester J. Vincent, Reg. No. 31,460; Glenn E. Von Tersch, Reg.No. 41,364; John Patrick Ward, Reg. No. 40,216; Mark L. Watson, Reg. No.P46,322; Thomas C. Webster, Reg. No. P46,154; and Norman Zafman, Reg.No. 26,250; my patent attorneys, and Raul Martinez, Reg. No. 46,904, mypatent agents; of BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP, with officeslocated at 12400 Wilshire Boulevard, 7th Floor, Los Angeles, Calif.90025, telephone (310) 207-3800, and Alan K. Aldous, Reg. No. 31,905;Robert D. Anderson, Reg. No. 33,826; Joseph R. Bond, Reg. No. 36,458;Richard C. Calderwood, Reg. No. 35,468; Paul W. Churilla, Reg. No.P47.495; Jeffrey S. Draeger, Reg. No. 41,000; Cynthia Thomas Faatz, RegNo. 39,973; Sean Fitzgerald, Reg. No. 32.027; John N. Greaves, Reg. No.40,362; Seth Z. Kalson, Reg. No. 40,670; David J. Kaplan, Reg. No.41,105; Charles A. Mirho, Reg. No. 41,199; Leo V. Novakoski, Reg. No.37,198; Naomi Obinata, Reg. No. 39,320; Thomas C. Reynolds, Reg. No.32,488; Kenneth M. Seddon, Reg. No. 43,105; Mark Seeley, Reg. No.32,299; Steven P. Skabrat, Reg. No. 36,279; Howard A. Skaist, Reg. No.36,008; Steven C. Stewart, Reg. No. 33,555; Raymond J. Werner, Reg. No.34,752; Robert G. Winkle, Reg. No. 37,474; Steven D. Yates, Reg. No.42,242, and Charles K. Young, Reg. No. 39,435; my patent attorneys,Thomas Raleigh Lane, Reg. No. 42,781; Calvin E. Wells; Reg. No. P43,256,Peter Lam, Reg. No. 44,855; Michael J. Nesheiwat, Reg. No. P47,819; andGene I. Su, Reg. No. 45,140; my patent agents, of INTEL CORPORATION; andJames R. Thein, Reg. No. 31,710, my patent attorney; with full power ofsubstitution and revocation, to prosecute this application and totransact all business in the Patent and Trademark Office connectedherewith.

What is claimed is:
 1. A method, comprising: determining whether anidentifier for dynamically loadable code; pushing the identifier onto aunidirectional communication link; determining whether an availabilityschedule for the dynamically loadable code; pushing the availabilityschedule onto the unidirectional communication link; and pushing thedynamically loadable code onto the unidirectional communication linkaccording to the availability schedule.
 2. The method of claim 1,further comprising: wherein the dynamically loadable code comprises aclass definition with an object oriented programming language; andwherein the identifier identifies the class definition.
 3. The method ofclaim 1, wherein the unidirectional communication link is a selected oneof: a television data transmission, an MPEG-2 transport stream, andIP-multicast.
 4. The method of claim 1, further comprising: receivingdata over the unidirectional communication link with a selected one of:a set top box, a personal digital assistant, a portable computer, ahandheld computer, and a wireless appliance.
 5. The method of claim 1,further comprising: receiving the identifier and the availabilityschedule over the unidirectional communication link; and retrieving thedynamically loadable code from said communication link according to theavailability schedule.
 6. The method of claim 5, further comprising:determining whether the dynamically loadable code is required forexecuting an application program; and performing said retrievingresponsive to said determining.
 7. An apparatus, comprising: a machineaccessible medium providing instructions, which when executed by amachine, are capable of directing the machine to perform the operationsof claim
 1. 8. The apparatus of claim 7, said instructions includingfurther instructions to direct the machine to perform the operations ofclaim
 2. 9. The apparatus of claim 7, wherein the unidirectionalcommunication link is a selected one of: a television data transmission,an MPEG-2 transport stream, and IP-multicast.
 10. The apparatus of claim7, said instructions including further instructions to direct themachine to perform the operations of claim
 4. 11. The apparatus of claim7, said instructions including further instructions to direct themachine to perform the operations of claim
 5. 12. The apparatus of claim11, said instructions including further instructions to direct themachine to perform the operations of claim
 6. 13. A method, comprising:preparing a manifest for dynamically loadable code, said manifestcomprising an identifier for dynamically loadable code, and anavailability schedule; pushing the manifest onto a unidirectionalcommunication link; and pushing the dynamically loadable code onto saidcommunication link according to the availability schedule.
 14. Themethod of claim 13, further comprising: wherein the dynamically loadablecode comprises a class definition in an object oriented programminglanguage; and wherein the identifier identifies the class definition.15. The method of claim 13, wherein the dynamically loadable code iswritten in a selected one of: Java, Objective-C, C++, SmallTalk,Modula-3, Component Object Model, and an object-oriented scriptinglanguage.
 16. The method of claim 13, wherein the unidirectionalcommunication link is a selected one of: a television data transmission,an MPEG-2 transport stream, and IP-multicast.
 17. The method of claim13, further comprising: receiving the unidirectional communication linkwith a selected one of: a set top box, a personal digital assistant, aportable computer, a handheld computer, and a wireless appliance. 18.The method of claim 13, further comprising: receiving the manifest oversaid communication link; recording the identifier and the availabilityschedule; and retrieving the dynamically loadable code when it is pushedonto said communication link according to the availability schedule. 19.The method of claim 14, further comprising: determining whether thedynamically loadable code is required for executing an applicationprogram; and performing said retrieving responsive to said determining.20. A method for mirroring a Java-type archive file, comprising:preparing a manifest for a Java-type archive file, said manifestcomprising identifiers for objects of the Java-type archive file, and anavailability schedule for said objects; pushing the manifest onto aunidirectional communication link; and pushing said objects of theJava-type archive file onto the unidirectional communication link inaccordance with the availability schedule.
 21. The method of claim 20,further comprising: executing programming code; determining whether anunavailable object is required for said executing; determining whetherthe manifest includes an identifier corresponding to the object; andreceiving said required object over the unidirectional communicationlink.
 22. The method of claim 21, further comprising: storing saidreceived object in a temporary memory location disposed within a device;wherein resetting the device causes said received object to bediscarded.
 23. The method of claim 20, wherein the manifest for theJava-type archive file includes purchasing data for said objects of theJava-type archive file, the method further comprising: identifying anunavailable object that is required for executing a program; determiningwhether the manifest includes an identifier corresponding to the object;receiving said required object over the unidirectional communicationlink; and purchasing said required object in accord with said purchasingdata.
 24. A method for obtaining dynamically loadable code over apush-only network, comprising: receiving, over the push-only network, amanifest for dynamically loadable code, said manifest comprising anidentifier for dynamically loadable code, and an availability schedule;and receiving, over the push-only network, the dynamically loadable codein accord with the availability schedule.
 25. The method of claim 24,wherein the dynamically loadable code comprises a selected one of: asingle object oriented object, a plurality of object oriented objectdefinitions, and a Dynamic Link Library (DLL).
 26. The method of claim24, further comprising: determining whether an application programrequires dynamically loadable code; and determining whether the manifestincludes an identifier corresponding to said dynamically loadable code.27. The method of claim 26, further comprising: inspecting a CLASSPATHenvironment for a class containing said required dynamically loadablecode; and determining whether said required dynamically loadable code isunavailable.
 28. The method of claim 27, further comprising: adding saidreceived dynamically loadable code to the CLASSPATH environment.
 29. Themethod of claim 24, wherein the dynamically loadable code comprises aJava-type programming language class, the method further comprising:inspecting a CLASSPATH environment for a class containing thedynamically loadable code; and determining whether said requireddynamically loadable code is unavailable, and responsive thereto,performing said receiving the dynamically loadable code.
 30. The methodof claim 24, further comprising: adding said received dynamicallyloadable code to a local storage for dynamically loadable code.
 31. Anapparatus, comprising: a machine accessible medium providinginstructions, which when executed by a machine, are capable of directingthe machine to perform: preparing a manifest for dynamically loadablecode, said manifest comprising an identifier for dynamically loadablecode, and an availability schedule; pushing the manifest onto aunidirectional communication link; and pushing the dynamically loadablecode onto said communication link according to the availabilityschedule.
 32. The apparatus of claim 31, said instructions includingfurther instructions to direct the machine to perform: receiving theunidirectional communication link with a selected one of: a set top box,a personal digital assistant, a portable computer, a handheld computer,and a wireless appliance.
 33. The apparatus of claim 31, saidinstructions including further instructions to direct the machine toperform: receiving the manifest over said communication link; recordingthe identifier and the availability schedule; and retrieving thedynamically loadable code when it is pushed onto said communication linkaccording to the availability schedule.
 34. The apparatus of claim 31,said instructions including further instructions to direct the machineto perform: determining whether the dynamically loadable code isrequired for executing an application program; and performing saidretrieving responsive to said determining.
 35. An apparatus formirroring a Java-type archive file, comprising: a machine accessiblemedium providing instructions, which when executed by a machine, arecapable of directing the machine to perform: preparing a manifest for aJava-type archive file, said manifest comprising identifiers for objectsof the Java-type archive file, and an availability schedule for saidobjects; pushing the manifest onto a unidirectional communication link;and pushing said objects of the Java-type archive file onto theunidirectional communication link in accordance with the availabilityschedule.
 36. The apparatus of claim 35, said instructions includingfurther instructions to direct the machine to perform: determiningwhether an unavailable object is required for executing an application;determining whether the manifest includes an identifier corresponding tothe object; and receiving said required object over the unidirectionalcommunication link.
 37. The apparatus of claim 36, said instructionsincluding further instructions to direct the machine to perform: storingsaid received object in a temporary memory location.
 38. The apparatusof claim 35, said instructions including further instructions to directthe machine to perform: including purchasing data for said objects ofthe Java-type archive file in the manifest; identifying an unavailableobject that is required for executing a program; determining whether themanifest includes an identifier corresponding to the object; receivingsaid required object over the unidirectional communication link; andpurchasing said required object in accord with said purchasing data. 39.An apparatus for obtaining dynamically loadable code over a push-onlynetwork, comprising: a machine accessible medium providing instructions,which when executed by a machine, are capable of directing the machineto perform: receiving, over the push-only network, a manifest fordynamically loadable code, said manifest comprising an identifier fordynamically loadable code, and an availability schedule; and receiving,over the push-only network, the dynamically loadable code in accord withthe availability schedule.
 40. The apparatus of claim 39, saidinstructions including further instructions to direct the machine toperform: determining whether an application program requires dynamicallyloadable code; and determining whether the manifest includes anidentifier corresponding to said dynamically loadable code.
 41. Theapparatus of claim 40, said instructions including further instructionsto direct the machine to perform: inspecting a CLASSPATH environment fora class containing said required dynamically loadable code; anddetermining whether said required dynamically loadable code isunavailable.
 42. The apparatus of claim 40, said instructions includingfurther instructions to direct the machine to perform: adding saidreceived dynamically loadable code to the CLASSPATH environment.
 43. Theapparatus of claim 39, said instructions including further instructionsto direct the machine to perform: inspecting a CLASSPATH environment fora class containing the dynamically loadable code; and determiningwhether said required dynamically loadable code is unavailable, andresponsive thereto, performing said receiving the dynamically loadablecode.
 44. A system, comprising: at least one processor; and a readablemedium having instructions encoded thereon, which when executed by theprocessor, are capable of directing the processor to perform: preparinga manifest for dynamically loadable code, said manifest comprising anidentifier for dynamically loadable code, and an availability schedule;pushing the manifest onto a unidirectional communication link; andpushing the dynamically loadable code onto said communication linkaccording to the availability schedule.
 45. The system of claim 44, saidinstructions including further instructions to direct the processor toperform: receiving the unidirectional communication link with a selectedone of: a set top box, a personal digital assistant, a portablecomputer, a handheld computer, and a wireless appliance.
 46. The systemof claim 44, said instructions including further instructions to directthe processor to perform: receiving the manifest over said communicationlink; recording the identifier and the availability schedule; andretrieving the dynamically loadable code when it is pushed onto saidcommunication link according to the availability schedule.
 47. A systemfor mirroring a Java-type archive file, comprising: at least oneprocessor; and a readable medium having instructions encoded thereon,which when executed by the processor, are capable of directing theprocessor to perform: preparing a manifest for a Java-type archive file,said manifest comprising identifiers for objects of the Java-typearchive file, and an availability schedule for said objects; pushing themanifest onto a unidirectional communication link; and pushing saidobjects of the Java-type archive file onto the unidirectionalcommunication link in accordance with the availability schedule.
 48. Thesystem of claim 47, said instructions including further instructions todirect the processor to perform: determining whether an unavailableobject is required for executing an application; determining whether themanifest includes an identifier corresponding to the object; andreceiving said required object over the unidirectional communicationlink.
 49. The system of claim 47, said instructions including furtherinstructions to direct the processor to perform: including purchasingdata for said objects of the Java-type archive file in the manifest;identifying an unavailable object that is required for executing aprogram; determining whether the manifest includes an identifiercorresponding to the object; receiving said required object over theunidirectional communication link; and purchasing said required objectin accord with said purchasing data.
 50. A system for obtainingdynamically loadable code over a push-only network, comprising: at leastone processor; and a readable medium having instructions encodedthereon, which when executed by the processor, are capable of directingthe processor to perform: receiving, over the push-only network, amanifest for dynamically loadable code, said manifest comprising anidentifier for dynamically loadable code, and an availability schedule;and receiving, over the push-only network, the dynamically loadable codein accord with the availability schedule.
 51. The system of claim 50,said instructions including further instructions to direct the processorto perform: determining whether an application program requiresdynamically loadable code; and determining whether the manifest includesan identifier corresponding to said dynamically loadable code.
 52. Thesystem of claim 50, said instructions including further instructions todirect the processor to perform: inspecting a CLASSPATH environment fora class containing said required dynamically loadable code; determiningwhether said required dynamically loadable code is unavailable; andadding said received dynamically loadable code to the CLASSPATHenvironment.